SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Call stack</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Call stack</span></span>

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .ambox{border:1px solid #a2a9b1;border-left:10px solid #36c;background-color:#fbfbfb;box-sizing:border-box}.mw-parser-output .ambox+link+.ambox,.mw-parser-output .ambox+link+style+.ambox,.mw-parser-output .ambox+link+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+style+.ambox,.mw-parser-output .ambox+.mw-empty-elt+link+link+.ambox{margin-top:-1px}html body.mediawiki .mw-parser-output .ambox.mbox-small-left{margin:4px 1em 4px 0;overflow:hidden;width:238px;border-collapse:collapse;font-size:88%;line-height:1.25em}.mw-parser-output .ambox-speedy{border-left:10px solid #b32424;background-color:#fee7e6}.mw-parser-output .ambox-delete{border-left:10px solid #b32424}.mw-parser-output .ambox-content{border-left:10px solid #f28500}.mw-parser-output .ambox-style{border-left:10px solid #fc3}.mw-parser-output .ambox-move{border-left:10px solid #9932cc}.mw-parser-output .ambox-protection{border-left:10px solid #a2a9b1}.mw-parser-output .ambox .mbox-text{border:none;padding:0.25em 0.5em;width:100%}.mw-parser-output .ambox .mbox-image{border:none;padding:2px 0 2px 0.5em;text-align:center}.mw-parser-output .ambox .mbox-imageright{border:none;padding:2px 0.5em 2px 0;text-align:center}.mw-parser-output .ambox .mbox-empty-cell{border:none;padding:0;width:1px}.mw-parser-output .ambox .mbox-image-div{width:52px}@media(min-width:720px){.mw-parser-output .ambox{margin:0 10%}}@media print{body.ns-0 .mw-parser-output .ambox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style>

<p>In <a href="Computer_science" title="Computer science">computer science</a>, a <b>call stack</b> is a <a href="Stack_(abstract_data_type)" title="Stack (abstract data type)">stack</a> <a href="Data_structure" title="Data structure">data structure</a> that stores information about the active <a href="Subroutine" class="mw-redirect" title="Subroutine">subroutines</a> and <a href="Block_(programming)" title="Block (programming)">inline blocks</a> of a <a href="Computer_program" title="Computer program">computer program</a>. This type of stack is also known as an <b>execution stack</b>, <b>program stack</b>, <b>control stack</b>, <b>run-time stack</b>, or <b>machine stack</b>, and is often shortened to simply the "<b>stack</b>". Although maintenance of the call stack is important for the proper functioning of most <a href="Software" title="Software">software</a>, the details are normally hidden and automatic in <a href="High-level_programming_language" title="High-level programming language">high-level programming languages</a>. Many computer <a href="Instruction_set" class="mw-redirect" title="Instruction set">instruction sets</a> provide special instructions for manipulating stacks.

</p><p>A call stack is used for several related purposes, but the main reason for having one is to keep track of the point to which each active subroutine should return control when it finishes executing. An active subroutine is one that has been called, but is yet to complete execution, after which control should be handed back to the point of call. Such activations of subroutines may be nested to any level (recursive as a special case), hence the stack structure. For example, if a subroutine <code>DrawSquare</code> calls a subroutine <code>DrawLine</code> from four different places, <code>DrawLine</code> must know where to return when its execution completes. To accomplish this, the <a href="Memory_address" title="Memory address">address</a> following the <a href="Instruction_(computer_science)" class="mw-redirect" title="Instruction (computer science)">instruction</a> that jumps to <code>DrawLine</code>, the <i><a href="Return_address_(computing)" class="mw-redirect" title="Return address (computing)">return address</a></i>, is pushed onto the top of the call stack as part of each call.

</p>

<div class="mw-heading mw-heading2"><h2 id="Description">Description</h2></div>

<p>Since the call stack is organized as a <a href="Stack_(abstract_data_type)" title="Stack (abstract data type)">stack</a>, the caller of a procedure pushes the return address onto the stack, and the called subroutine, when it finishes, <a href="Pop_(computer_programming)" class="mw-redirect" title="Pop (computer programming)">pulls or pops</a> the return address off the call stack and transfers control to that address; similarly, the prolog of an inline block pushes a stack frame and the epilog pops it. If a called subroutine calls on yet another subroutine, it will push another return address onto the call stack, and so on, with the information stacking up and unstacking as the program dictates. If the pushing consumes all of the space allocated for the call stack, an error called a <a href="Stack_overflow" title="Stack overflow">stack overflow</a> occurs, generally causing the program to <a href="Crash_(computing)" title="Crash (computing)">crash</a>. Adding a block's or subroutine's entry to the call stack is sometimes called "winding", and removing entries "unwinding".

</p><p>There is usually exactly one call stack associated with a running program (or more accurately, with each <a href="Task_(computers)" class="mw-redirect" title="Task (computers)">task</a> or <a href="Thread_(computer_science)" class="mw-redirect" title="Thread (computer science)">thread</a> of a <a href="Process_(computing)" title="Process (computing)">process</a>), although additional stacks may be created for <a href="Signal_(computing)" class="mw-redirect" title="Signal (computing)">signal</a> handling or <a href="Cooperative_multitasking" title="Cooperative multitasking">cooperative multitasking</a> (as with <a href="Setcontext" title="Setcontext">setcontext</a>). Since there is only one in this important context, it can be referred to as <i>the</i> stack (implicitly "of the task"); however, in the <a href="Forth_programming_language" class="mw-redirect" title="Forth programming language">Forth programming language</a> the <i>data stack</i> or <i>parameter stack</i> is accessed more explicitly than the call stack and is commonly referred to as <i>the</i> stack (see below).

</p><p>In <a href="High-level_programming_language" title="High-level programming language">high-level programming languages</a>, the specifics of the call stack are usually hidden from the programmer. They are given access only to a set of functions, and not the memory on the stack itself. This is an example of <a href="Abstraction_(computer_science)" title="Abstraction (computer science)">abstraction</a>. Most <a href="Assembly_language" title="Assembly language">assembly languages</a>, on the other hand, require programmers to be involved in manipulating the stack. The actual details of the stack in a <a href="Programming_language" title="Programming language">programming language</a> depend upon the <a href="Compiler" title="Compiler">compiler</a>, <a href="Operating_system" title="Operating system">operating system</a>, and the available <a href="Instruction_set" class="mw-redirect" title="Instruction set">instruction set</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Functions_of_the_call_stack">Functions of the call stack</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">See also: <a href="Stack-based_memory_allocation" title="Stack-based memory allocation">Stack-based memory allocation</a></div>

<p>As noted above, the primary purpose of a call stack is to <i>store the return addresses</i>. When a subroutine is called, the location (address) of the instruction at which the calling routine can later resume must be saved somewhere. Using a stack to save the return address has important advantages over some alternative <a href="Calling_convention" title="Calling convention">calling conventions</a>, such as saving the return address before the beginning of the called subroutine or in some other fixed location. One is that each task can have its own stack, and thus the subroutine can be <a href="Thread_safety" title="Thread safety">thread-safe</a>, that is, able to be active simultaneously for different tasks doing different things. Another benefit is that by providing <a href="Reentrancy_(computing)" title="Reentrancy (computing)">reentrancy</a>, <a href="Recursion_(computer_science)" title="Recursion (computer science)">recursion</a> is automatically supported. When a function calls itself recursively, a return address needs to be stored for each activation of the function so that it can later be used to return from the function activation. Stack structures provide this capability automatically.

</p><p>Depending on the language, operating system, and machine environment, a call stack may serve additional purposes, including, for example:

</p>

<dl><dt>Local data storage</dt>

<dd>A subroutine frequently needs memory space for storing the values of <a href="Local_variable" title="Local variable">local variables</a>, the variables that are known only within the active subroutine and do not retain values after it returns. It is often convenient to allocate space for this use by simply moving the top of the stack by enough to provide the space. This is very fast when compared to <a href="Dynamic_memory_allocation" class="mw-redirect" title="Dynamic memory allocation">dynamic memory allocation</a>, which uses the <a href="Heap_(programming)" class="mw-redirect" title="Heap (programming)">heap space</a>. Note that each separate activation of a subroutine gets its own separate space in the stack for locals.</dd>

<dd>Similarly, an <a href="Block_(programming)" title="Block (programming)">inline block</a> may allocate a stack frame for local variables. As with a call frame, the values are lost when the block exits.</dd>

<dt>Parameter passing</dt>

<dd>Subroutines often require that values for <a href="Parameter_(computer_science)" class="mw-redirect" title="Parameter (computer science)">parameters</a> be supplied to them by the code which calls them, and it is not uncommon that space for these parameters may be laid out in the call stack. Generally if there are only a few small parameters, <a href="Processor_register" title="Processor register">processor registers</a> will be used to pass the values, but if there are more parameters than can be handled this way, memory space will be needed. The call stack works well as a place for these parameters, especially since each call to a subroutine, which will have differing values for parameters, will be given separate space on the call stack for those values. In <a href="Object-oriented_language" class="mw-redirect" title="Object-oriented language">object-oriented languages</a> such as <a href="C%2B%2B" title="C++">C++</a>, the list of parameters may also include the <a href="This_(computer_science)" class="mw-redirect" title="This (computer science)"><code>this</code> pointer</a>.</dd>

<dt>Evaluation stack</dt>

<dd>Operands for arithmetic or logical operations are most often placed into registers and operated on there. However, in some situations the operands may be stacked up to an arbitrary depth, which means something more than registers must be used (this is the case of <a href="Register_allocation#Principle" title="Register allocation">register spilling</a>). The stack of such operands, rather like that in an <a href="RPN_calculator" class="mw-redirect" title="RPN calculator">RPN calculator</a>, is called an evaluation stack, and may occupy space in the call stack.</dd>

<dt>Enclosing subroutine context</dt>

<dd>Some programming languages (e.g., <a href="Pascal_(programming_language)" title="Pascal (programming language)">Pascal</a> and <a href="Ada_(programming_language)" title="Ada (programming language)">Ada</a>) support declaration of <a href="Nested_functions" class="mw-redirect" title="Nested functions">nested subroutines</a>, which are allowed to access the context of their enclosing routines, i.e., the parameters and local variables within the scope of the outer routines. Such static nesting can repeat (a function declared within a function declared within a function…). The implementation must provide a means by which a called function at any given static nesting level can reference the enclosing frame at each enclosing nesting level. This reference is commonly implemented by a pointer to the frame of the most recently activated instance of the enclosing function, called a "downstack link" or "static link", to distinguish it from the "dynamic link" that refers to the immediate caller (which need not be the static parent function).</dd>

<dd>Instead of a static link, the references to the enclosing static frames may be collected into an array of pointers known as a <i>display</i> which is indexed to locate a desired frame. The depth of a routine's lexical nesting is a known constant, so the size of a routine's display is fixed. Also, the number of containing scopes to traverse is known, the index into the display is also fixed. Usually, a routine's display is located in its own stack frame, but the <a href="Burroughs_large_systems" class="mw-redirect" title="Burroughs large systems">Burroughs B6500</a> implemented such a display in hardware which supported up to 32 levels of static nesting.</dd>

<dd>The display entries denoting containing scopes are obtained from the appropriate prefix of the caller's display. An inner routine which recurses creates separate call frames for each invocation. In this case, all of the inner routine's static links point to the same outer routine context.</dd>

<dt>Enclosed block context</dt>

<dd>In some languages, e.g., <a href="ALGOL_60" title="ALGOL 60">ALGOL 60</a>, <a href="PL/I" title="PL/I">PL/I</a>, a block within a procedure may have its own local variables, allocated on block entry and freed on block exit. Similarly, the block may have its own exception handlers, deactivated at block exit.</dd>

<dt>Other return state</dt>

<dd>Beside the return address, in some environments there may be other machine or software states that need to be restored when a subroutine returns. This might include things like privilege level, exception-handling information, arithmetic modes, and so on. If needed, this may be stored in the call stack just as the return address is.</dd></dl>

<p>

The typical call stack is used for the return address, locals, and parameters (known as a <i>call frame</i>). In some environments there may be more or fewer functions assigned to the call stack. In the <a href="Forth_(programming_language)" title="Forth (programming language)">Forth programming language</a>, for example, ordinarily only the return address, counted loop parameters and indexes, and possibly local variables are stored on the call stack (which in that environment is named the <i>return stack</i>), although any data can be temporarily placed there using special return-stack handling code so long as the needs of calls and returns are respected; parameters are ordinarily stored on a separate <i>data stack</i> or <i>parameter stack</i>, typically called <i>the</i> stack in Forth terminology even though there is a call stack since it is usually accessed more explicitly. Some Forths also have a third stack for <a href="Floating-point" class="mw-redirect" title="Floating-point">floating-point</a> parameters.

</p>

<div class="mw-heading mw-heading2"><h2 id="Structure">Structure</h2></div>

<p>A call stack is composed of <b>stack frames</b> (also called <i>activation records</i> or <i>activation frames</i>). These are <a href="Machine_dependent" class="mw-redirect" title="Machine dependent">machine dependent</a> and <a href="Application_binary_interface" title="Application binary interface">ABI</a>-dependent data structures containing subroutine state information. Each stack frame corresponds to an invocation of a subroutine that has not yet completed with a return.<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> The stack frame at the top of the stack is for the currently executing routine. For example, if a subroutine named <code>DrawLine</code> is currently running, having been called by a subroutine <code>DrawSquare</code>, the top part of the call stack might be laid out like in the adjacent picture.

</p><p>A diagram like this can be drawn in either direction as long as the placement of the top, and so direction of stack growth, is understood. Architectures differ as to whether call stacks grow towards higher addresses or towards lower addresses, so the logic of any diagram is not dependent on this addressing choice by convention.

</p><p>While it is actively executing, with its frame at the stack top, a routine can access the information within its frame as needed.<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup> The stack frame typically includes at least the following items (in the order pushed):

</p>

<ul><li>the arguments (parameter values) passed to the routine on the call stack (if any);</li>

<li>the return address back to the routine's caller (e.g. in the <code>DrawLine</code> stack frame, an address into <code>DrawSquare</code>'s code), if that is saved on the call stack rather than a register; and</li>

<li>space for the local variables of the routine (if any).</li></ul>

<div class="mw-heading mw-heading3"><h3 id="Stack_and_frame_pointers">Stack and frame pointers</h3></div>

<p>When stack frame sizes can differ, such as between different functions or between invocations of a particular function, popping a frame off the stack does not constitute a fixed decrement of the <b>stack pointer</b>. At function return, the stack pointer is instead restored to the <b>frame pointer</b>, the value of the stack pointer just before the function was called. Each stack frame contains a frame pointer to the top of the frame immediately below. The stack pointer is a mutable register shared between all invocations. A frame pointer of a given invocation of a function is a copy of the stack pointer as it was before the function was invoked.<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p><p>The locations of all other fields in the frame can be defined relative either to the top of the frame, as negative offsets of the stack pointer, or relative to the top of the frame below, as positive offsets of the frame pointer. The location of the frame pointer itself must inherently be defined as a negative offset of the stack pointer.

</p>

<div class="mw-heading mw-heading3"><h3 id="Storing_the_address_to_the_caller's_frame">Storing the address to the caller's frame</h3></div>

<p>In most systems a stack frame has a field to contain the previous value of the frame pointer register, the value it had while the caller was executing. For example, the stack frame of <code>DrawLine</code> would have a memory location holding the frame pointer value that <code>DrawSquare</code> uses (not shown in the diagram above). The value is saved upon entry to the subroutine. Having such a field in a known location in the stack frame enables code to access each frame successively underneath the currently executing routine's frame, and also allows the routine to easily restore the frame pointer to the <i>caller's</i> frame, just before it returns.

</p>

<div class="mw-heading mw-heading3"><h3 id="Lexically_nested_routines">Lexically nested routines</h3></div>

<div role="note" class="hatnote navigation-not-searchable">Further information: <a href="Nested_function" title="Nested function">Nested function</a> and <a href="Non-local_variable" title="Non-local variable">Non-local variable</a></div>

<p>Programming languages that support <a href="Nested_function" title="Nested function">nested subroutines</a> also have a field in the call frame that points to the stack frame of the <i>latest</i> activation of the procedure that most closely encapsulates the callee, i.e. the immediate <i>scope</i> of the callee. This is called an <i>access link</i> or <i>static link</i> (as it keeps track of static nesting during dynamic and recursive calls) and provides the routine (as well as any other routines it may invoke) access to the local data of its encapsulating routines at every nesting level. Some architectures, compilers, or optimization cases store one link for each enclosing level (not just the immediately enclosing), so that deeply nested routines that access shallow data do not have to traverse several links; this strategy is often called a "display".<sup id="cite_ref-4" class="reference"><a href="#cite_note-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</p><p>Access links can be optimized away when an inner function does not access any (non-constant) local data in the encapsulation, as is the case with pure functions communicating only via arguments and return values, for example. Some historical computers, such as the <a href="Electrologica_X8" title="Electrologica X8">Electrologica X8</a> and somewhat later the <a href="Burroughs_large_systems" class="mw-redirect" title="Burroughs large systems">Burroughs large systems</a>, had special "display registers" to support nested functions, while compilers for most modern machines (such as the ubiquitous x86) simply reserve a few words on the stack for the pointers, as needed.

</p>

<div class="mw-heading mw-heading3"><h3 id="Overlap">Overlap</h3></div>

<p>For some purposes, the stack frame of a subroutine and that of its caller can be considered to overlap, the overlap consisting of the area where the parameters are passed from the caller to the callee. In some environments, the caller pushes each argument onto the stack, thus extending its stack frame, then invokes the callee. In other environments, the caller has a preallocated area at the top of its stack frame to hold the arguments it supplies to other subroutines it calls. This area is sometimes termed the <i>outgoing arguments area</i> or <i>callout area</i>. Under this approach, the size of the area is calculated by the compiler to be the largest needed by any called subroutine.

</p>

<div class="mw-heading mw-heading3"><h3 id="Call_site_processing">Call site processing</h3></div>

<p>Usually the call stack manipulation needed at the site of a call to a subroutine is minimal (which is good since there can be many call sites for each subroutine to be called). The values for the actual arguments are evaluated at the <a href="Call_site" title="Call site">call site</a>, since they are specific to the particular call, and either pushed onto the stack or placed into registers, as determined by the used <a href="Calling_convention" title="Calling convention">calling convention</a>. The actual call instruction, such as "branch and link", is then typically executed to transfer control to the code of the target subroutine.

</p>

<div class="mw-heading mw-heading3"><h3 id="Subroutine_entry_processing">Subroutine entry processing</h3></div>

<p>In the called subroutine, the first code executed is usually termed the <a href="Function_prologue" class="mw-redirect" title="Function prologue">subroutine prologue</a>, since it does the necessary housekeeping before the code for the statements of the routine is begun.

</p><p>For instruction set architectures in which the instruction used to call a subroutine puts the return address into a register, rather than pushing it onto the stack, the prologue will commonly save the return address by pushing the value onto the call stack, although if the called subroutine does not call any other routines it may leave the value in the register. Similarly, the current stack pointer and/or frame pointer values may be pushed.

</p><p>If frame pointers are being used, the prologue will typically set the new value of the frame pointer register from the stack pointer. Space on the stack for local variables can then be allocated by incrementally changing the stack pointer.

</p><p>The <a href="Forth_(programming_language)" title="Forth (programming language)">Forth programming language</a> allows explicit winding of the call stack (called there the "return stack").

</p>

<div class="mw-heading mw-heading3"><h3 id="Return_processing">Return processing</h3></div>

<p>When a subroutine is ready to return, it executes an epilogue that undoes the steps of the prologue. This will typically restore saved register values (such as the frame pointer value) from the stack frame, pop the entire stack frame off the stack by changing the stack pointer value, and finally branch to the instruction at the return address. Under many calling conventions, the items popped off the stack by the epilogue include the original argument values, in which case there usually are no further stack manipulations that need to be done by the caller. With some calling conventions, however, it is the caller's responsibility to remove the arguments from the stack after the return.

</p>

<div class="mw-heading mw-heading3"><h3 id="Unwinding">Unwinding</h3></div>

<p>Returning from the called function will pop the top frame off the stack, perhaps leaving a return value. The more general act of popping one or more frames off the stack to resume execution elsewhere in the program is called <b>stack unwinding</b> and must be performed when non-local control structures are used, such as those used for <a href="Exception_handling_(programming)" title="Exception handling (programming)">exception handling</a>. In this case, the stack frame of a function contains one or more entries specifying exception handlers. When an exception is thrown, the stack is unwound until a handler is found that is prepared to handle (catch) the type of the thrown exception.

</p><p>Some languages have other control structures that require general unwinding. <a href="Pascal_programming_language" class="mw-redirect" title="Pascal programming language">Pascal</a> allows a global <a href="GOTO" class="mw-redirect" title="GOTO">goto</a> statement to transfer control out of a nested function and into a previously invoked outer function. This operation requires the stack to be unwound, removing as many stack frames as necessary to restore the proper context to transfer control to the target statement within the enclosing outer function. Similarly, C has the <a href="Setjmp.h" title="Setjmp.h"><code>setjmp</code> and <code>longjmp</code></a> functions that act as non-local gotos. <a href="Common_Lisp" title="Common Lisp">Common Lisp</a> allows control of what happens when the stack is unwound by using the <code>unwind-protect</code> special operator.

</p><p>When applying a <a href="Continuation" title="Continuation">continuation</a>, the stack is (logically) unwound and then rewound with the stack of the continuation. This is not the only way to implement continuations; for example, using multiple, explicit stacks, application of a continuation can simply activate its stack and wind a value to be passed. The <a href="Scheme_(programming_language)" title="Scheme (programming language)">Scheme programming language</a> allows arbitrary <a href="Thunk_(functional_programming)" class="mw-redirect" title="Thunk (functional programming)">thunks</a> to be executed in specified points on "unwinding" or "rewinding" of the control stack when a continuation is invoked.

</p>

<div class="mw-heading mw-heading2"><h2 id="Inspection">Inspection</h2></div>

<div role="note" class="hatnote navigation-not-searchable">See also: <a href="Profiling_(computer_programming)" title="Profiling (computer programming)">Profiling (computer programming)</a></div>

<p>The call stack can sometimes be inspected as the program is running. Depending on how the program is written and compiled, the information on the stack can be used to determine intermediate values and function call traces. This has been used to generate fine-grained automated tests,<sup id="cite_ref-5" class="reference"><a href="#cite_note-5"><span class="cite-bracket">[</span>5<span class="cite-bracket">]</span></a></sup> and in cases like Ruby and <a href="Smalltalk" title="Smalltalk">Smalltalk</a>, to implement first-class continuations. As an example, the <a href="GNU_Debugger" title="GNU Debugger">GNU Debugger</a> (GDB) implements interactive inspection of the call stack of a running, but paused, C program.<sup id="cite_ref-6" class="reference"><a href="#cite_note-6"><span class="cite-bracket">[</span>6<span class="cite-bracket">]</span></a></sup>

</p><p>Taking regular-time samples of the call stack can be useful in profiling the performance of programs as, if a subroutine's address appears in the call stack sampling data many times, it is likely to act as a code bottleneck and should be inspected for performance problems.

</p>

<div class="mw-heading mw-heading2"><h2 id="Security">Security</h2></div>

<div role="note" class="hatnote navigation-not-searchable">Main article: <a href="Stack_buffer_overflow" title="Stack buffer overflow">Stack buffer overflow</a></div>

<p>In a language with free pointers or non-checked array writes (such as in C), the mixing of control flow data which affects the execution of code (the return addresses or the saved frame pointers) and simple program data (parameters or return values) in a call stack is a security risk, and is possibly <a href="Exploit_(computer_security)" title="Exploit (computer security)">exploitable</a> through <a href="Stack_buffer_overflow" title="Stack buffer overflow">stack buffer overflows</a>, which are the most common type of <a href="Buffer_overflow" title="Buffer overflow">buffer overflow</a>.

</p><p>One such attack involves filling one buffer with arbitrary executable code, and then overflowing this or some other buffer to overwrite some return address with a value that points directly to the executable code. As a result, when the function returns, the computer executes that code. This kind of an attack can be blocked with <a href="W%5EX" title="W^X">W^X</a>, but similar attacks can succeed even with W^X protection enabled, including the <a href="Return-to-libc_attack" title="Return-to-libc attack">return-to-libc attack</a> or the attacks coming from <a href="Return-oriented_programming" title="Return-oriented programming">return-oriented programming</a>. Various mitigations have been proposed, such as storing arrays in a completely separate location from the return stack, as is the case in the Forth programming language.<sup id="cite_ref-7" class="reference"><a href="#cite_note-7"><span class="cite-bracket">[</span>7<span class="cite-bracket">]</span></a></sup>

</p>

/* start https://en.wikipedia.org/ */

.mw-parser-output .portalbox{padding:0;margin:0.5em 0;display:table;box-sizing:border-box;max-width:175px;list-style:none}.mw-parser-output .portalborder{border:1px solid var(--border-color-base,#a2a9b1);padding:0.1em;background:var(--background-color-neutral-subtle,#f8f9fa)}.mw-parser-output .portalbox-entry{display:table-row;font-size:85%;line-height:110%;height:1.9em;font-style:italic;font-weight:bold}.mw-parser-output .portalbox-image{display:table-cell;padding:0.2em;vertical-align:middle;text-align:center}.mw-parser-output .portalbox-link{display:table-cell;padding:0.2em 0.2em 0.2em 0.3em;vertical-align:middle}@media(min-width:720px){.mw-parser-output .portalleft{margin:0.5em 1em 0.5em 0}.mw-parser-output .portalright{clear:right;float:right;margin:0.5em 0 0.5em 1em}}

/* end https://en.wikipedia.org/ */

</style>

/* start https://en.wikipedia.org/ */

.mw-parser-output .div-col{margin-top:0.3em;column-width:30em}.mw-parser-output .div-col-small{font-size:90%}.mw-parser-output .div-col-rules{column-rule:1px solid #aaa}.mw-parser-output .div-col dl,.mw-parser-output .div-col ol,.mw-parser-output .div-col ul{margin-top:0}.mw-parser-output .div-col li,.mw-parser-output .div-col dd{page-break-inside:avoid;break-inside:avoid-column}

/* end https://en.wikipedia.org/ */

</style><div class="div-col" style="column-width: 20em;">

<ul><li><a href="Automatic_memory_allocation" class="mw-redirect" title="Automatic memory allocation">Automatic memory allocation</a></li>

<li><a href="Calling_convention" title="Calling convention">Calling convention</a></li>

<li><a href="Coroutine" title="Coroutine">Coroutine</a></li>

<li><a href="Overhead_(computing)" title="Overhead (computing)">Overhead (computing)</a></li>

<li><a href="Spaghetti_stack" class="mw-redirect" title="Spaghetti stack">Spaghetti stack</a></li>

<li><a href="Stack-based_memory_allocation" title="Stack-based memory allocation">Stack-based memory allocation</a></li>

<li><a href="Stack_machine" title="Stack machine">Stack machine</a></li>

<li><a href="Stack_trace" title="Stack trace">Stack trace</a></li></ul>

</div>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist reflist-columns references-column-width" style="column-width: 30em;">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20190912213638/http://www.math.utah.edu/docs/info/gdb_7.html">"Examining the Stack"</a>. <i>University of Utah</i>. Archived from <a rel="nofollow" class="external text" href="https://www.math.utah.edu/docs/info/gdb_7.html">the original</a> on September 12, 2019<span class="reference-accessdate">. Retrieved <span class="nowrap">April 3,</span> 2025</span>.</cite></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text"><cite id="CITEREFKrzyzanowski2018" class="citation web cs1">Krzyzanowski, Paul (February 16, 2018). <a rel="nofollow" class="external text" href="https://people.cs.rutgers.edu/~pxk/419/notes/frames.html">"Stack frames"</a>. <i><a href="Rutgers_University" title="Rutgers University">Rutgers University</a></i>. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20210828140609/https://people.cs.rutgers.edu/~pxk/419/notes/frames.html">Archived</a> from the original on 2021-08-28<span class="reference-accessdate">. Retrieved <span class="nowrap">December 19,</span> 2021</span>.</cite></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20130225162302/http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Mips/stack.html">"Understanding the Stack"</a>. <i>cs.umd.edu</i>. 2003-06-22. Archived from <a rel="nofollow" class="external text" href="http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Mips/stack.html">the original</a> on 2013-02-25<span class="reference-accessdate">. Retrieved <span class="nowrap">2014-05-21</span></span>.</cite></span>

</li>

<li id="cite_note-4"><span class="mw-cite-backlink"><b><a href="#cite_ref-4">^</a></b></span> <span class="reference-text"><a href="https://wiki.c2.com/?AlternativeMicroprocessorDesign" class="extiw external" title="c2:AlternativeMicroprocessorDesign">Alternative Microprocessor Design</a></span>

</li>

<li id="cite_note-5"><span class="mw-cite-backlink"><b><a href="#cite_ref-5">^</a></b></span> <span class="reference-text"><cite id="CITEREFMcMasterMemon2006" class="citation conference cs1">McMaster, S.; Memon, A. (2006). <a rel="nofollow" class="external text" href="http://www.cs.umd.edu/~atif/papers/McMasterMemonISSRE2006.pdf"><i>Call Stack Coverage for GUI Test-Suite Reduction</i></a> <span class="cs1-format">(PDF)</span>. 17th International Symposium on Software Reliability Engineering (<a href="ISSRE" title="ISSRE">ISSRE</a> '06). pp. <span class="nowrap">33–</span>44. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.88.873">10.1.1.88.873</a></span>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FISSRE.2006.19">10.1109/ISSRE.2006.19</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-7695-2684-5</bdi>.</cite></span>

</li>

<li id="cite_note-6"><span class="mw-cite-backlink"><b><a href="#cite_ref-6">^</a></b></span> <span class="reference-text"><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://web.archive.org/web/20210414194505/http://www.chemie.fu-berlin.de/chemnet/use/info/gdb/gdb_7.html">"Debugging with GDB: Examining the Stack"</a>. <i>chemie.fu-berlin.de</i>. 1997-10-17. Archived from <a rel="nofollow" class="external text" href="http://www.chemie.fu-berlin.de/chemnet/use/info/gdb/gdb_7.html">the original</a> on 2021-04-14<span class="reference-accessdate">. Retrieved <span class="nowrap">2014-12-16</span></span>.</cite></span>

</li>

<li id="cite_note-7"><span class="mw-cite-backlink"><b><a href="#cite_ref-7">^</a></b></span> <span class="reference-text">Doug Hoyte. <a rel="nofollow" class="external text" href="http://www.hcsw.org/reading/forth.txt">"The Forth Programming Language - Why YOU should learn it"</a>.</span>

</li>

</ol></div>

<div class="mw-heading mw-heading2"><h2 id="Further_reading">Further reading</h2></div>

<ul><li><cite id="CITEREFDijkstra1960" class="citation journal cs1"><a href="Edsger_W._Dijkstra" title="Edsger W. Dijkstra">Dijkstra, E. W.</a> (1960). "Recursive Programming". <i>Numerische Mathematik</i>. <b>2</b> (1): <span class="nowrap">312–</span>318. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1007%2FBF01386232">10.1007/BF01386232</a>.</cite></li>

<li><cite id="CITEREFWilsonJohnstoneNeelyBoles1995" class="citation book cs1">Wilson, P. R.; Johnstone, M. S.; Neely, M.; Boles, D. (1995). "Dynamic storage allocation: A survey and critical review". <i>Memory Management</i>. Lecture Notes in Computer Science. Vol. 986. pp. <span class="nowrap">1–</span>116. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <span class="id-lock-free" title="Freely accessible"><a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.275">10.1.1.47.275</a></span>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1007%2F3-540-60368-9_19">10.1007/3-540-60368-9_19</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-3-540-60368-9</bdi>.</cite></li>

<li><cite class="citation book cs1">"2.4. The Stack". <a rel="nofollow" class="external text" href="http://bitsavers.trailing-edge.com/components/intel/MCS4/MCS-4_Assembly_Language_Programming_Manual_Dec73.pdf"><i>MCS-4 Assembly Language Programming Manual - The INTELLEC 4 Microcomputer System Programming Manual</i></a> <span class="cs1-format">(PDF)</span> (Preliminary ed.). Santa Clara, California, USA: <a href="Intel_Corporation" class="mw-redirect" title="Intel Corporation">Intel Corporation</a>. December 1973. pp. <span class="nowrap">2-7 –</span> <span class="nowrap">2-8</span>. MCS-030-1273-1. <a rel="nofollow" class="external text" href="https://web.archive.org/web/20200301235541/http://bitsavers.trailing-edge.com/components/intel/MCS4/MCS-4_Assembly_Language_Programming_Manual_Dec73.pdf">Archived</a> <span class="cs1-format">(PDF)</span> from the original on 2020-03-01<span class="reference-accessdate">. Retrieved <span class="nowrap">2020-03-02</span></span>.</cite> (NB. <a href="Intel" title="Intel">Intel</a>'s 4-bit processor <a href="Intel_4004" title="Intel 4004">4004</a> implements an internal stack rather than an in-memory stack.)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><a rel="nofollow" class="external text" href="http://www.eventhelix.com/RealtimeMantra/Basics/CToAssemblyTranslation.htm">Function Calling and Frame Pointer Operations in 68000</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20100724120705/http://www.eventhelix.com/RealtimeMantra/Basics/CToAssemblyTranslation.htm">Archived</a> 2010-07-24 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a></li>

<li><a rel="nofollow" class="external text" href="http://www.nongnu.org/libunwind/">The libunwind project</a> - a platform-independent unwind API</li></ul>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hlist dl,.mw-parser-output .hlist ol,.mw-parser-output .hlist ul{margin:0;padding:0}.mw-parser-output .hlist dd,.mw-parser-output .hlist dt,.mw-parser-output .hlist li{margin:0;display:inline}.mw-parser-output .hlist.inline,.mw-parser-output .hlist.inline dl,.mw-parser-output .hlist.inline ol,.mw-parser-output .hlist.inline ul,.mw-parser-output .hlist dl dl,.mw-parser-output .hlist dl ol,.mw-parser-output .hlist dl ul,.mw-parser-output .hlist ol dl,.mw-parser-output .hlist ol ol,.mw-parser-output .hlist ol ul,.mw-parser-output .hlist ul dl,.mw-parser-output .hlist ul ol,.mw-parser-output .hlist ul ul{display:inline}.mw-parser-output .hlist .mw-empty-li{display:none}.mw-parser-output .hlist dt::after{content:": "}.mw-parser-output .hlist dd::after,.mw-parser-output .hlist li::after{content:" · ";font-weight:bold}.mw-parser-output .hlist dd:last-child::after,.mw-parser-output .hlist dt:last-child::after,.mw-parser-output .hlist li:last-child::after{content:none}.mw-parser-output .hlist dd dd:first-child::before,.mw-parser-output .hlist dd dt:first-child::before,.mw-parser-output .hlist dd li:first-child::before,.mw-parser-output .hlist dt dd:first-child::before,.mw-parser-output .hlist dt dt:first-child::before,.mw-parser-output .hlist dt li:first-child::before,.mw-parser-output .hlist li dd:first-child::before,.mw-parser-output .hlist li dt:first-child::before,.mw-parser-output .hlist li li:first-child::before{content:" (";font-weight:normal}.mw-parser-output .hlist dd dd:last-child::after,.mw-parser-output .hlist dd dt:last-child::after,.mw-parser-output .hlist dd li:last-child::after,.mw-parser-output .hlist dt dd:last-child::after,.mw-parser-output .hlist dt dt:last-child::after,.mw-parser-output .hlist dt li:last-child::after,.mw-parser-output .hlist li dd:last-child::after,.mw-parser-output .hlist li dt:last-child::after,.mw-parser-output .hlist li li:last-child::after{content:")";font-weight:normal}.mw-parser-output .hlist ol{counter-reset:listitem}.mw-parser-output .hlist ol>li{counter-increment:listitem}.mw-parser-output .hlist ol>li::before{content:" "counter(listitem)"\a0 "}.mw-parser-output .hlist dd ol>li:first-child::before,.mw-parser-output .hlist dt ol>li:first-child::before,.mw-parser-output .hlist li ol>li:first-child::before{content:" ("counter(listitem)"\a0 "}

/* end https://en.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r1236075235">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbox{box-sizing:border-box;border:1px solid #a2a9b1;width:100%;clear:both;font-size:88%;text-align:center;padding:1px;margin:1em auto 0}.mw-parser-output .navbox .navbox{margin-top:0}.mw-parser-output .navbox+.navbox,.mw-parser-output .navbox+.navbox-styles+.navbox{margin-top:-1px}.mw-parser-output .navbox-inner,.mw-parser-output .navbox-subgroup{width:100%}.mw-parser-output .navbox-group,.mw-parser-output .navbox-title,.mw-parser-output .navbox-abovebelow{padding:0.25em 1em;line-height:1.5em;text-align:center}.mw-parser-output .navbox-group{white-space:nowrap;text-align:right}.mw-parser-output .navbox,.mw-parser-output .navbox-subgroup{background-color:#fdfdfd}.mw-parser-output .navbox-list{line-height:1.5em;border-color:#fdfdfd}.mw-parser-output .navbox-list-with-group{text-align:left;border-left-width:2px;border-left-style:solid}.mw-parser-output tr+tr>.navbox-abovebelow,.mw-parser-output tr+tr>.navbox-group,.mw-parser-output tr+tr>.navbox-image,.mw-parser-output tr+tr>.navbox-list{border-top:2px solid #fdfdfd}.mw-parser-output .navbox-title{background-color:#ccf}.mw-parser-output .navbox-abovebelow,.mw-parser-output .navbox-group,.mw-parser-output .navbox-subgroup .navbox-title{background-color:#ddf}.mw-parser-output .navbox-subgroup .navbox-group,.mw-parser-output .navbox-subgroup .navbox-abovebelow{background-color:#e6e6ff}.mw-parser-output .navbox-even{background-color:#f7f7f7}.mw-parser-output .navbox-odd{background-color:transparent}.mw-parser-output .navbox .hlist td dl,.mw-parser-output .navbox .hlist td ol,.mw-parser-output .navbox .hlist td ul,.mw-parser-output .navbox td.hlist dl,.mw-parser-output .navbox td.hlist ol,.mw-parser-output .navbox td.hlist ul{padding:0.125em 0}.mw-parser-output .navbox .navbar{display:block;font-size:100%}.mw-parser-output .navbox-title .navbar{float:left;text-align:left;margin-right:0.5em}body.skin--responsive .mw-parser-output .navbox-image img{max-width:none!important}@media print{body.ns-0 .mw-parser-output .navbox{display:none!important}}

/* end https://en.wikipedia.org/ */

</style></div><div role="navigation" class="navbox" aria-labelledby="Application_binary_interface_(ABI)74" style="padding:3px"><table class="nowraplinks mw-collapsible autocollapse navbox-inner" style="border-spacing:0;background:transparent;color:inherit"><tbody><tr><th scope="col" class="navbox-title" colspan="2"><style data-mw-deduplicate="TemplateStyles:r1239400231">

/* start https://en.wikipedia.org/ */

.mw-parser-output .navbar{display:inline;font-size:88%;font-weight:normal}.mw-parser-output .navbar-collapse{float:left;text-align:left}.mw-parser-output .navbar-boxtext{word-spacing:0}.mw-parser-output .navbar ul{display:inline-block;white-space:nowrap;line-height:inherit}.mw-parser-output .navbar-brackets::before{margin-right:-0.125em;content:"[ "}.mw-parser-output .navbar-brackets::after{margin-left:-0.125em;content:" ]"}.mw-parser-output .navbar li{word-spacing:-0.125em}.mw-parser-output .navbar a>span,.mw-parser-output .navbar a>abbr{text-decoration:inherit}.mw-parser-output .navbar-mini abbr{font-variant:small-caps;border-bottom:none;text-decoration:none;cursor:inherit}.mw-parser-output .navbar-ct-full{font-size:114%;margin:0 7em}.mw-parser-output .navbar-ct-mini{font-size:114%;margin:0 4em}html.skin-theme-clientpref-night .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}@media(prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .navbar li a abbr{color:var(--color-base)!important}}@media print{.mw-parser-output .navbar{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div id="Application_binary_interface_(ABI)74" style="font-size:114%;margin:0 4em"><a href="Application_binary_interface" title="Application binary interface">Application binary interface</a> (ABI)</div></th></tr><tr><th scope="row" class="navbox-group" style="width:1%">Parts,<br>conventions</th><td class="navbox-list-with-group navbox-list navbox-odd hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Data_structure_alignment" title="Data structure alignment">Alignment</a></li>

<li><a href="Calling_convention" title="Calling convention">Calling convention</a></li>

<li><a href="Library_(computing)" title="Library (computing)">Library</a>

<ul><li><a href="Static_library" title="Static library">static</a></li></ul></li>

<li><a href="Machine_code" title="Machine code">Machine code</a></li>

<li><a href="Memory_segmentation" title="Memory segmentation">Memory segmentation</a></li>

<li><a href="Name_mangling" title="Name mangling">Name mangling</a></li>

<li><a href="Object_code" title="Object code">Object code</a></li>

<li><a href="Opaque_pointer" title="Opaque pointer">Opaque pointer</a></li>

<li><a href="Position-independent_code" title="Position-independent code">Position-independent code</a></li>

<li><a href="Relocation_(computing)" title="Relocation (computing)">Relocation</a></li>

<li><a href="System_call" title="System call">System call</a></li>

<li><a href="Virtual_method_table" title="Virtual method table">Virtual method table</a></li></ul>

</div></td></tr><tr><th scope="row" class="navbox-group" style="width:1%">Related topics</th><td class="navbox-list-with-group navbox-list navbox-even hlist" style="width:100%;padding:0"><div style="padding:0 0.25em">

<ul><li><a href="Binary-code_compatibility" title="Binary-code compatibility">Binary-code compatibility</a></li>

<li><a href="Foreign_function_interface" title="Foreign function interface">Foreign function interface</a></li>

<li><a href="Language_binding" title="Language binding">Language binding</a></li>

<li><a href="Linker_(computing)" title="Linker (computing)">Linker</a>

<ul><li><a href="Dynamic_linker" title="Dynamic linker">dynamic</a></li></ul></li>

<li><a href="Loader_(computing)" title="Loader (computing)">Loader</a></li>

<li><a href="Year_2038_problem" title="Year 2038 problem">Year 2038 problem</a></li></ul>

</div></td></tr></tbody></table></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-06-02" href="https://en.wikipedia.org/wiki/?title=Call_stack&oldid=1293596982">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>